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Configurable protocol engine 

FIELD OF THE INVENTION 

5 

The present invention relates generally to communication systems. In particular the 
invention concems conununication protocols and configurability thereof. 

BACKGROUND OF THE INVENTION 

10 

Many backbones of modem conununication such as GSM (Global System for mobile 
commxmications) and UMTS (Universal Mobile Telecommunications System) wireless 
systems and undoubtedly the Internet as the most adopted wired data network transfer 
multiple types of data over a number of different interfaces by utilizing a plurality of 

15 protocols. Concerning both payload data and signalling transfer, the development of 
protocols has been separated in many diverging directions naturally depending on the 
various requirements originally set for the specific protocol under development. A 
protocol as an entity can be concretised as a composition of rales describing how to 
transfer data across the network and the functionality to implement the data transfer in 

20 practise. 

As modem appUcations and the increased amount of data traffic in general put more 
and more pressure on the used protocols, especially the efficiency of a protocol 
implementation used in the transport system should be optimized. The protocol 

25 implementation is often considered as a maximally efficient one when it provides all 
the needed communication services in such a way that the use of the protocol requires 
only minimal amoimt of hardware and network resources in the end system. The 
needed communication services typically cover the essential functionalities according 
to a requested Quality of Service (QoS) level. QoS represents the desired performance 

30 properties of a network service generally including throughput, delay, and priority 
levels for data transfer. 

The communication services provided by the protocols in existing general-purpose 
protocol stacks such as the well-known Open System Intercoimection (OSI) reference 
35 stack by ISO (International Standardization Organization) with seven layers (physical, 
data link, network, transport, session, presentation, appUcation) or the closely related 
TCP/IP (Transmission Control Protocol / Internet Protocol) reference stack are not 
always adequate for all specific purposes the one may come up with. See reference [1] 
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for further information about the above protocols. In order for a protocol to provide the 
necessary services and at the same time, place only minimal requirements for available 
hardware and network resources, the protocol has to be designed according to some 
specific requirements, 

5 

The user of a protocol may be e.g. a lower or higher level protocol or an application. 
Services provided by the protocol may be accessed via service primitives that define 
the fomiat and content of the exchanged information. Primitives tibiat are exchanged 
through Service Access Points (SAP) between successive protocol layers (or between 

10 equivalent protocol layers located in different systems) may include user originated 
data, control and management parameters. The primitives can be divided into four 
basic classes: requests, indications, responses, and confirmations. Typically a higher 
layer protocol entity requests some service firom a lower layer protocol, receives 
indication about events firom lower layer protocols, and responds to events taken by the 

15 lower layer protocol, whereas the lower layer protocol may confirm the events 
requested by the upper layer protocol. 

Protocol functionalities required by the services are realized with data processing, 
control and management functions respectively. Control functions, e.g. flow, queue, 
20 and timing functions, are used to control the data flow through the protocol, for 
example. Data processing functions, e.g. encryption, error detection, error correction, 
and fragmentation, manipulate the data itself instead. Management functions like 
management information base (MIB) functions are associated with monitoring, 
network level control, power management, protocol state etc. 

25 

The control and data functions can be considered as a sequential set of operations, 
which are executed upon data flow through the protocol. In addition to processing data, 
each operation can among others branch, buffer, and synchronize data flow. On the 
contrary, the management functions can be viewed as a set of operations performed 
30 substantially in parallel with both control and data functions. 

As described hereinbefore, a protocol implementation has a certain structure defining 
relations between the protocol functions. The structure fixes the consistence of the data 
flow and defines the composition of control, data, and management functions. 

35 

A common problem with contemporary protocol arrangements, however, arises from 
the evident staticity of the protocol structures tailored for some specific use. Such 
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protocols may be effective from the user's perspective if any modifications or 
additions are not needed thereto but in case of change in the desired requirements the 
protocol may have to be at least partly if not completely re-implemented with a 
renewed hardware and/or software structure. 

5 

PubUcation [2] discloses a design concept of a generic protocol stack for an adaptive 
terminal. As in mobile networks the features of both UMTS/GSM mobile system and 
the DECT (Digital Enhanced Cordless Telecommunications) cordless phone system 
might seem advantageous, the adaptive terminal should incorporate a protocol stack 

10 supporting all these systems with some shared resources. Therefore, a protocol stack - 
skeleton is built upon which the system specific parts are then adapted to. The 
publication concentrates on finding similarities between GSM, UMTS, and DECT 
systems from which DECT and UMTS seem to match each other reasonably well in 
contrast to the older GSM system that has a slightly differing structure what comes to 

15 the overall layer division. 



PubUcation [3] discloses a protocol and a protocol framework comprising a generic 
model of protocol processing, a metaheader protocol supporting per-packet 
configuration of protocol function, and a set of protocol ftinctions. Protocol fimctions 

20 are not layered and thus they do not attach headers (or extract them) to data units; 
header attach/detach is performed by the generic model that defines the interface 
between the actual protocol infirastructure and fimctions thereof. Metaheader protocol 
implements multiplexing and composition mechanisms and contains information both 
for retrieving state information of the incoming data imit efficiently and for indicating 

25 which set of protocol fimctions should be applied to the incoming data unit and 
possibly in what order liiey should be utilized. Protocol configurations can be 
dynamically altered via metaheaders that all data units carry. Configurability is carried 
out on a pluraUty of levels: global configuration, connection based configuration 
(defined at connection start-up by both ends of the communication), and message 

30 specific configuration. Moreover, protocol fimctions are divided into three classes: 
generic, functions affecting the metaheaders, and fimctions affecting the intemal 
protocol structure but not appearing in the metaheaders (like data flow control). 

Notwithstanding liie aforementioned improvements in protocol planning a number of 
35 defects are still lefl; more or less intact. In general sense, the prior art methods can be 
classified as follows: in the first method being the most obvious one a preferred 
protocol stack may be selected from several permanently fixed complete stacks. This 
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approach causes a multiplicily of overhead originated from the duplication of similar 
functions included in different stacks and the inclusion of xmnecessary fimctionaUties 
in the end result. The second method solves the problem by offering various partial 
protocols used to compose application specific complete stacks. In this method the 
5 configuration does not modify the functionality of a single partial protocol that is 
already fixed and used as is [2]. This method includes less overhead than the first 
meihod, but there is still functional duplication or uimecessary functionality that cannot 
be avoided. The most flexible method provides atomic protocol functions composing 
the dynamic stmcture [3]. The problems not addressed by this method are related, for 
10 example, to the scheduling of protocol processing and management of the protocol in 
efficient manner. 



SUMMARY OF THE INVENTION 

15 

The object of the present invention is to alleviate aforesaid defects of contemporary, 
protocol arrangements. The object is achieved by introducing a concept of a 
configurable protocol engine (CPE) that supports both dynamic boot-time and run-time 
protocol change schemes wit automated management of the protocol structure. The 

20 CPE is a framework for dynamically creating protocols from general-purpose protocol: 
fimctions according to given requirements. Furthermore, as disclosed by figure 1 the^ 
protocol assembly 110 is done in order to meet the requirements set by the protocol 
services 102 and desired QoS 104, and at the same time, by taking the limitations in the 
hardware 106 and network resources 108 into account. After the protocol assembly, the 

25 configured CPE 112 is utilized in the communication process as a normal 
commimication protocol. Reconfiguration of the CPE is done to adapt the protocol 
engine to changes in e.g. the required services and available resources. Network 
elements or terminals utilizing the CPE can negotiate or agree in each separate case on 
the used protocol structure. 

30 

The utility of the invention is based on a variety of issues. The CPE offers a clear 
function-based method to compose the preferred protocol. The CPE supports dynamic 
re-configuration based on e.g. service requirements, platform, and networking 
enviromnent via its configuration manager, and it's flexible and capable of 
35 implementing entirely new special purpose protocols as well as parts of already 
existing protocols with only necessary properties eihbedded. The user can add 
functions and interfaces to the CPE libraries, which can be then included in the 
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implemented protocol by modifying the configuration. A protocol stack may be 
implemented as a whole or in respect to the preferred portions only. With reference to 
figure 2 disclosing two examples, the CPE can be used to realize e.g. one or more 
protocol layers of the OSI reference model. In the &st case, reference sign 202 points 
5 to the data link layer implemented with the CPE the user of which is then the network 
layer 204. In the second example the CPE carries out the functions of five different 
layers, see reference sign 208, namely presentation, session, transport, network and 
data link layer. The CPE protocol user is thus the topmost application layer 206. An 
appUcation or a part thereof may directly utilize the functionalities provided by the 

10 CPE. E.g. various data processing methods like data partitioning, coding, and 
encryption previously included in the application may be embedded to and performed 
by the CPE. Execution of the methods may be dynamic and depend on the current 
network conditions, for example, and that way repositioning such methods to a lower 
layer reduces the processing latency due to a lower proximity to the physical interface 

15 in addition to obvious savings in the application memory and processing costs. 
Furthermore, functions are reused and thus time and effort are saved if compared to the 
scenario wherein everything is developed from the scratch. Still further, the service 
primitives can be effectively scheduled by utilizing the CPE scheduling algorithm. The 
accomplished re-use of basic building blocks like functions for a plurality of purposes 

20 in the constructed protocol obviously saves also memory space in the executing device.. 

The CPE may be used in both mobile and fixed networks by various network elements 
like servers, computers or by personal tenninal devices such as (multimode) mobile 
terminals, communication enabled PDAs (Personal Digital Assistant), and other 
25 wireless conmnmication devices. Obvious applications include e.g. video, sound, and 
other data transmission related services over both packet-switched and circuit-switched 
connections. 

Protocol engine configuration is substantially a two-step process. First, the 
30 configuration information is delivered to the protocol engine in a readable form, e.g. as 
a configuration message including configuration parameters. The information may 
relate to required protocol services, desired QoS, resources of the end system and the 
used network etc. Then, the received information is used for assembling a suitable 
protocol meeting the requirements. Protocol services that are typically needed include 
35 e.g. 

-error detection for detecting transmission errors in transferred data. 



wo 2005/041527 



PCT/FI2003/000803 



6 

-error control for controlling and preventing transmission errors, 
-corruption control for handling corrupted data packets, 

-data retransmission for enabling retransmission of corrupted/lost data packets, 
-packet replication control for detecting replicated data packets, 
5 -encryption/decryption for encrypting/decrypting data, 

-ordered delivery of data for ensuring the correct ordering of data packets 
senl/received, and 

-flow control for preventing buffer overflow situations. 

10 Referring to figure 3, the CPE internal architecture is illustrated. Arrows depict 
conamunication between different elements. The CPE includes a configuration 
manager 308, general configurable core 306 and specific libraries of protocol functions 
314 and interfaces 310. The configuration manager 308 produces the protocol 
structure. The core module 306 is protocol independent, and can thus be used for 

15 constructing different types of protocol architectures. The libraries 310, 314 include 
functions for data processing and interfaces providing protocol services to adjacent 
protocol layers. Communication with the CPE takes place through three different SAPs 
(see the legends and reference signs 318, 320, 322 in the figure). Two of the SAPs 318, 
322 are used for exchanging data between the CPE and the upper 302 (CPE user) and 

20 lower 316 protocol layer. The third SAP 320 is used for delivering configuration 
information for flie CPE. In this sketch, a separate management user 304 dehvers the 
configuration information but in practise the actual CPE user may provide that 
information as well. In addition, the management SAP 320 may be physically attached 
to the data SAP 318 (e.g. a shared physical interface), albeit the logical separation 

25 between those still holds true. MIB 312 stores the current configuration data and can 
be used for storing management statistics and other information. In addition to mere 
configuration information, also different service primitives are exchanged through the 
SAPs. In the CPE architecture, interfaces 310 handle the data delivery between the 
SAPs and titie controlling core 306 of the CPE. The configuration information shall 

30 case-specifically specify which interfaces are needed in the protocol assembly in 
question. 

The core 306 forms the kernel of each protocol. Viewed at the highest level it 
schedules the overall protocol processing. The core 306 receives various protocol 
35 service primitives from the interfaces 310 and stores them to queues. The CPE 
scheduling algorithm then chooses primitives firom the queues according to predefined 
criteria and calls necessary protocol functions depending on the current configuration. 
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The outgoing primitives are sent from the core 306 back to adjacent protocol layers 
through the interfaces 310. 

The configuration and construction of the CPE is done according to different 
5 requirements by the configuration manager 308. Sources of requirements can be e.g. 
platform capabilities, networking environment, and data transfer quality of service. 
Platform capabilities are the available functions 314. The functions 314 can be in the 
form of software that is executed on general hardware or function on some dedicated 
hardware. The functions 314 are associated with information about their effect on 
10 processing requirements, such as processing delay, data throughput, and memory 
allocations. 

The networking environment defines the technologies used for transferring data 
between network nodes. Basically, the requirement for CPE is to achieve adequate 
15 compatibility with peer nodes. The networking technologies, such as compatibility 
with different network standards in the case of multimode terminal, are thus not 
limited. 

Data transfer quality of a service is associated with the requirements placed by a 
20 protocol user for the received data transfer performance. These parameters are used 
together with platform capabilities for constructing a protocol that best meets the 
requirements. 

For configurability, the core 306 includes a convertible CPE protocol processing 
25 scheduler and flexible queuing capabilities. Configuration provided to the core 306 
defines the general protocol structure, the used CPE scheduling algorithm and 
primitive queues for the services. 

The core 306 itself is independent of the soxurce that generates the configuration. The 
30 configuration can be permanently user defined when implementing a static protocol 
with CPE, or the configuration manager 308 can dynamically generate it. 

According to the invention, a configurable protocol engine (CPE) for configuring and 
constructing a commimication protocol comprises 

35 -means for receiving service primitives, 

-means for receiving configuration information, 
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-means for managing the CPE configuration on the basis of the configuration 
information, 

-means for controlling and scheduling at least part of internal processing in the 
CPE on the basis of the CPE configuration, 

5 -means for interfacing an upper and lower protocol layer on the basis of the CPE 

configuration, and 

-a number of fimctions for processing data in accordance with the CPE 
configuration. 



10 The means for interfacing refer to soflware and/or hardware means depending on the 
case. If the CPE is implemented as pure software, such means are of software (code) 
nature and thus somewhat easily configurable, that, however, may be at least 
functionally connected to the hardware means (and may at least partially control them) 
if the CPE is used to implement the layer directly above the physical one. 

15 Alternatively, if the CPE implementation has actual hardware parts embedded to take 
care of interfacing, e.g. in a form of transceiver or physical network adapter 
controllable by the CPE, such means may be considered as hardware as well. 

In another aspect of the invention, a method for configuring a configurable protocol 
20 engine (CPE) in order to construct a commimication protocol has the steps of 

-obtaining configuration information, 

-defining the CPE configuration on the basis of said configuration information, 
and 

-adapting the CPE to the defined CPE configuration, whereby at least one action is 
25 performed, said action selected fi^om the group of: an interface towards an external 

.entity is implemented, a queue for a service primitive is implemented, and a 
function to be used for processing data included in a service primitive is 
determined. 



30 The implementation of a queue refers to at least defining (and maintaining) the 
association of a certain primitive type (or some other factor conmion to a number of 
primitives) with the queue. The queue may not have to be physically realized though 
by allocating memory space etc before a first primitive of that type really enters the 
CPE and needs to be stored in a queue. 
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The function determination in the above aspect refers to either selecting a certain 
function from a plurality of available functions on the basis of the CPE configuration, 
or to receiving a (new) function, for example, as a binary code or some less complete 
indication thereof (information like a number of parameters to cultivate an existing 
5 function, or a direct reference to an existing function) from an extemal entity, in the 
latter case the function determination being substantially included in the received 
configuration information. 

In a further aspect of the invention, a computer program for implementing at least part 
10 of a configurable protocol engine (CPE) for constructing a protocol comprises code 
means 

to define and manage the CPE configuration on the basis of available configuration 
information, 

to schedule processing of received service primitives on the basis of the CPE 
15 configuration, and 

to provide a number of functions for processing data included in the service primitives 
in accordance with the CPE configuration. 

Still in a further aspect of the invention, an electronic device for implementing a 
20 configurable protocol engine (CPE) capable of receiving and processing service 
primitives comprises processing and memory means for processing and storing 
instructions and data, and data transfer means for transferring data, said device 
arranged to receive configuration information, to manage the CPE configuration on the 
basis of the configuration information, to schedule at least part of the internal 
25 processing within the CPE on the basis of the CPE configuration, and to process 
received service primitives in accordance with the CPE configuration. 

The term "engine" refers generally to a general-purpose core, which is responsible for 
implementing the main functionality. Similarly a "protocol engine" can be considered 

30 as a general core part of a conmiunication protocol that implements at least most of the 
conmiunication between the intemal parts. A protocol engine can thus be used as 
implementation of protocols. A protocol implemented with a protocol engine can be 
seen from the upper and lower layers as a normal protocol. It may have the upper and 
lower layer interfaces and also a virtual peer interface. A protocol engine may 

35 implement a single protocol layer, a whole stack, or just part of the stack. A 
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configurable protocol engine is able to implement different conmiunication protocols 
by utilizing a number of general-purpose functions. 

In an embodiment of the invention, one option for utilizing the CPE concept in 
5 protocol design is presented. Configuration information, protocol assembly and 
protocol runtime execution are discussed in detail. The constructed protocol may be 
used in, for example, transferring video data with different levels of 
protection/encryption depending on the connection type and other parameters. 

10 Dependent claims disclose embodiments of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Hereinafter the invention is described in more detail by reference to the attached 
1 5 drawings, wherein 

Fig. 1 discloses the CPE configuration process on a general level. 

Fig. 2 illustrates the CPE's usability in relation to the common OSI model. 

Fig. 3 depicts the CPE internals. 

20 Fig. 4 discloses one option for protocol service categorization by utilizing the OSI 

model. 

Fig. 5 depicts data flow inside the CPE upon receiving and processing data. 

Fig. 6 is a CPE UML class diagram. 

Fig. 7 is a CPE UML architecture diagram. 
25 Fig. 8 is a CPE core UML architecture diagram. 

Fig. 9 is a UML architecture diagram of the CPE scheduler. 

Fig. 1 0 depicts one option for the function selection process in the CPE. 

Fig. 1 1 visualises a video transmission system utilizing the CPE. 

Fig. 12A is flow diagram of the method for constructing and managing a protocol 
30 with the CPE. 

Fig. 12B further discloses the CPE configuration process in more detail. 

Fig. 1 3 is a block diagram of a device capable of hosting the CPE. 

4 

3 5 DETAILED DESCRIPTION OF THE EMBODIMENT OF THE INVENTION 
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Figures 1-3 were already discussed in conjunction with the description of the summary 
of the invention. 

Figure 4 discloses, by way of example only, how typical protocol services may be 
5 categorized in relation to the OSI reference model. The protocol functions each of 
which realizes a simple protocol task are stored in the CPE function library. Whenever 
the CPE must be capable of providing protocol services that cover the most common 
services offered by the layers from 2 to 6 in the OSI model, the function library must 
include several protocol functions to carry out such services. Generally speaking, the 
10 protocol services can be divided into four categories according to which layer they are 
normally provided on. 

The first category 408 of services is related to physical link services including link 
management and frame control. Also error detection services, radio management, and 
1 5 power save management are included in this category. 

The second category 406, link protocol related services, includes data segmentation 
and reassembly services. Also flow control and error control services are present. The 
services in the second category 406 are normally provided by the upper part of the data 
20 link layer. 

Network layer services form the third category 404. These are congestion control and 
routing related services. Also segmentation and flow control, as well as error control 
services are included. In the OSI reference model, such services are provided on the 
25 network and transport layers. 

The fourth category 402, commxmication service related services, includes services 
concerning session management, data presentation, and data compression. These 
services are related to the session and presentation layers of the OSI model. 

30 

The protocol functions may then be selected to die CPE functions library by utilizing 
the knowledge about the most common services supported by communication 
protocols. Such functions may include 

35 -parity bit calculation for calculating parity bit for the sent/received data, 

-cyclic Redundancy Check (CRC) for calculating checksum for data using CRC, 
-forward Error Correction (FEC) for implementing FEC as an error control method. 
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-automatic Repeat Request (ARQ) for implementing ARQ of damaged or lost packets, 
-data retransmission for retransmitting data when requested, 

-packet replication check for checking packet duplicates in case of packet replication, 
-data encryption standard (DES) for encrypting/decrypting data, 
5 -data re-sequencing for sequencing the data packets in the right order in case of 
unordered arrival of packets, 

-data acknowledgement function for acknowledging the received data, 

-sequence nxmibering for adding sequence number for data packets interpreting them 

at the receiving end, 

10 -data segmentation for segmenting data packets to smaller packets/frames if needed, 
-data reassembly for reassembling the segmented data, and 

-power save for ordering the CPE utilizing device to go into power save mode on idle 
periods. 

15 Next, the CPE top-level elements are described in more detail by referring first to 
figure 5 disclosing data flow through the CPE between the upper and lower protocol 
layers. In the figure, only a single scenario wherein data (-service primitive) is 
received JBrom the upper layer to be processed and finally deUvered to the lower layer is 
illustrated with arrows for simplicity reasons. Configuration management 508 is 

20 described later in the text. When data arrives jfrom the upper (or the lower) protocol 
layer, it passes through the instantiated CPE interface(s) 510 and enters the CPE core 
506. Therein the data is placed into a data queue according to the priority of the data. 
Next, the data is retrieved from the queue and delivered to a protocol function 514 
where it is processed. The core 506 handles the intemal data traffic between the data 

25 queues and protocol functions 514, and the data is passed through a series of 
instantiated (filled in the figure) protocol functions 514 in a certain order. When the 
data arrives to a protocol function 514, the function processes the data and retums it 
back to the CPE core 506 that sends the data to the next protocol function 514. If the 
next protocol function 514 is busy handling other data, the data is stored to the data 

30 queues to be processed when the function 514 is available again. After the data has 
passed through all the needed protocol functions 514, it is placed into the outgoing data 
queue, from where it is sent to upper/lower protocol layer through an appropriate CPE 
interface 510 and SAP. 

35 A UML (Unified Modeling Language) class diagram of the CPE is presented in figure 
6 with relevant associations and compositions marked. As UML is nowadays a 
standard tool for describing software systems the average person skilled in the art is 
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ought to be familiar with it. However, further information about the UML notation is 
available at the OMG (Object Management Group) homepage on the Intemet [4] if 
needed. The CPE includes Protocollnterfaces 602, ProtocolCore 604, ProtocolMIB 
606, Functions 608, and ConfigurationManager 610 top-level classes, of which 
5 ProtocoUnterfaces 602, Functions 608, and ProtocolMIB 606 classes must be realised 
according to the implemented protocol. 

Correspondingly, a UML architecture diagram of the CPE is presented in figure 7. The 
CPE communicates with the environment through two ports. The user data port 702 
10 (UserDataPort) is used by upper and lower layer protocol users. Both of these entities 
use data and management services of the particular protocol. The other port, 
management port 704 (UserMngPort) is used by the management user who configures 
and manages the CPE itself. The Core of CPE includes great majority of the CPE 
functionality, and is thus described in more detail below. 

15 

The controlling core is the nerve centre of the CPE. It contains most of the CPE 
functionality since it controls the execution of the assembled protocol and is 
responsible for reconfiguring the CPE in case of changes in the service requirements or 
in available resources. The core contains data queues for different priority class data 
20 and is responsible for initializing the data queues according to the configuration 
information. The core also handles the initialization of all internal processes, functions, 
and interfaces. 

The core is divided into three sub-classes as depicted in the UML architecture diagram 
25 of figure 8. The Core configurator 804 is responsible for applying the CPE 
configuration, and it is controlled by the configuration manager through the 
management port. The configurator block 804 distributes the current configuration to 
other blocks by, for example, responding to the configuration inquiries. The CPE 
scheduler 802 schedules the processing of the primitives received firom the interfaces 
30 and stores waiting primitives to the primitive queues 810. Data is then retrieved firom 
the queues 806 at a right moment in accordance with e.g. the priority levels of data, 
and delivered to a proper protocol function. Finally, the core returns the processed data 
to the queues of outgoing data and from there to the CPE interfaces. 

35 Internal architecture of the CPE scheduler is presented in the architecture diagram of 
figure 9. In addition to the scheduler sub-block 906 corresponding to the scheduler 
class, the CPE scheduler includes also three control sub-blocks, PrimitiveControl 902, 



wo 2005/041527 PCT/FI2003/000803 



14 

QueueControl 904, and FunctionConlxol 908, to control conununication with external 
blocks. The primitiveControl 902 receives primitives from the interfaces and forwards 
them to proper queues according to the priority thereof (indicated by the primitive), 
and vice versa. The QueueControl 904 handles the queues it contains (for example, 
5 instantiation and termination of Queue objects) and provides queue services to other 
blocks. The scheduler 906 sub-block selects primitives from the queues according to 
the scheduler algorithm that utilizes queue priorities and forwards primitives to the 
functions via the FunctionControl 908. The FunctionControl 908 handles fimction calls 
from the Scheduler 906 and forwards processed primitives back to the queues through 
10 the scheduler 906. A certain primitive may be delivered to a plurality of ftmctions one 
at a time. The association between a certain primitive and a certain group of functions 
is specified in the FunctionControl 908 class as well as the proper order for their 
execution. Whenever a primitive is targeted to a function already in use, the primitive 
is returned back to the queue imtil the function becomes available again. 

15 

Considering the data flow during the scheduling phase, the CPE core receives 
primitives from the interfaces and they are stored in the queues with the help of 
primitive controller 902. There are separate queues 904 for different primitive types, 
which allows prioritising. When the CPE scheduler 906 is activated to process the 
20 primitives, the CPE scheduler algorithm selects the next queue to process. A primitive 
is received from the selected queue and the function controller 908 resolves the next 
function in the primitive processing sequence and calls the function. When the function 
(or a plurality of required functions respectively) finishes the processing, the primitive 
is stored back to the queue 904. 

25 

The CPE is configured through a configuration manager as mentioned before. The 
configuration manager is in this particular embodiment used only for the configuration 
and reconfiguration of the CPE thus its main responsibilities include, for example, 
reception of the configuration information from the CPE management user. The 

30 configuration manager analyses the configuration information and formulates 
necessary instmctions for the CPE core about which functions need to be instantiated, 
which interfaces are required, and what kind of data queues have to be established. 
Information about the current configuration is stored in the MIB. This includes the 
information about the protocol functions included in the protocol assembly and the 

35 information about the available hardware and network resources. The information 
stored in the MIB is used at least by the CPE core. 
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The configuration information consists of several different elements: required protocol 
services and a required service level for each service, available hardware resources, 
parameters concerning the characteristics of the used network, information about the 
upper and lower protocol layers between which the CPE resides, and also about the 
5 desired QoS, which in the CPE refers to e.g. a number of data priority levels needed. 

The protocol services required by the CPE user are listed in the configuration 
information. The list consists of one or more protocol services available in CPE. The 
protocol services can be offered by using a suitable set of CPE protocol functions 
10 introduced hereinbefore, for example. The required miiiimum service level (Qmin) for 
each service can be announced as an integer value from 1 to 5. 

Information about the available hardware resources can be specified by varioxis 
parameters as well: available physical memory, available processor power, and the 
1 5 battery power level in the physical device etc. 

Also different parameters conceming the characteristics of the used network shall be 
defined: the available network bandwidth. Bit Error Rate (BER), the Maximum 
Transfer Unit (MTU) size, jitter for packet transfer in the network, and information 
20 about the used transfer medium. The last parameter can be used to advertise whether 
the network is wireless or wired. 

Information about the surrounding protocol layers is stated in the configuration 
information with e.g. two parameters: the upper protocol layer and the lower protocol 
25 layer announciag the corresponding protocol layers in the OSI model. 

QoS is supported in the CPE data delivery by, for example, dividing data into different 
priority classes. The last parameter in the configuration information states the number 
of desired priority levels for data. 

30 

One feasible option for the CPE configuration information is summarized in the 
following table 1 . Value ranges and used units of the configuration parameters are also 
presented. 



35 



wo 2005/041527 PCT/FI2003/000803 



16 



Table 1. 



Infoimation Element 


■•i.:-\V Descriptibn; \ ' • • -^.i 


List of required services 
and a required minimum 
service level for each 
service 


The required protocol services presented as a list. 
The available protocol services are: 

• Error detection 

• Error control 

• Corruption control 

• Data retransmission 

• Packet replication control 

• pTinTvntion & decrvntion 

• Ordered delivery of data 

• Flow control. 


/iLvdllClUiC? XlaltiVVCllC 

resources 


Parameters describing the available hardware 
resources in the end system: 

• Processor power (mteger value > 0, Million 
Instructions Per Second, MIPS) 

• Physical memory (integer value > 0, KB) 


Network characteristics 


Parameters describing the characteristics of the used 
network: 

• Network bandwidth (integer value > 0, Kb/s) 

• BER (real value > 0, no units) 

• MTU (integer value > 0, octets) 


* 

Surrounding protocol 
layers 


Numbers representing the corresponding OSI layers 
for the protocol layers above and below CPE. 
• Upper protocol layer (integer value 3-7, no 

xmits) 


QoS 


Desired QoS is expressed as a number defining the 
desired priority level. 

• Priority levels (integer value 1 - 1 0, no units) 



As seen from the above table, in this case the QoS and the associated priority level has 
been expressed as a simple niraieric parameter having values between 1 and 10 for 
5 simplicity reasons. In practice, nmnerous QoS algorithms and definitions exist with a 
plurality of different parameters. Such alternative methods are similarly feasible in 
providing priority information to the CPE for further utilization. Correspondin^y, 
"Surrounding protocol layers'* element may be used for indicating also the used 
protocol version (IPv4 versus IPv6, for example) and other protocol or protocol layer 
10 specific information, not just the layer in which the surrounding protocols are located. 
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As mentioned earlier, the configuration and reconfiguration of CPE comprises 
delivering the configuration information to CPE and creating a protocol assembly 
according to that information. After that, the configured CPE is used for data transfer 
as a normal protocol. 

5 

After specifying the configuration information and delivering it to CPE the available 
hardware resources and the parameters concerning the used network axe analyzed and 
itiflyimnm values for e.g. three cost factors are set. The cost factors are numerical 
values that present the relative influence on the load that the created protocol assembly 
10 puts on the available hardware resources and on the used network. 

The three cost factors are defined for each fimction as follows: D for overhead traffic, 
P for processor power, and M for memory. All of those are described as an integer 
value from 1 to 10, with 1 corresponding to the lowest relative influence. 

15 

The factor D describes the relative amoimt of overhead traffic that is generated by the 
function in question. For example, data acknowledgement fimction generates overhead 
traffic by sending acknowledgement messages. 

20 The factor P describes the relative level of processor power needed for executing the 
function. For example, encryption function puts relatively high load on the processor 
where as, for example, the execution of a parity bit calculation function requires less 
processor power. 

25 The M factor describes the relative amoimt of physical memory needed if the function 
is included in the protocol assembly. For example, data retransmission function 
requires some kind of data buffering abihty and that requires relatively high amount of 
physical memory. 

* 

30 In addition to the cost factors, a Q-value is defined for each function. It specifies the 
level of service the function is capable of providing. For example, an error detection 
service can be provided with a parity bit calculation function or with a CRC (Cyclic 
Redundancy Check) function. With CRC, more errors can be detected from the 
received data. Therefore the CRC function has a higher Q-value than the parity bit 

35 calculation function. 
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Each function contains e.g. six different parameters: name, three cost factors M, P, and 
D, the level of service Q, and finally the function dependencies specifying the other 
functions required in the protocol assembly with the one in question. 

5 The selection of functions to implement the required services is done in the following 
maimer for each of the services: The Qmin value of the service is compared to Q- value 
(Qi) of the functions capable of providing the service. Next, the cost factor values (Di, 
Pi, Mi) of the functions having 

10 Qi>Qmin (1) 

are compared to the maximum values for the three cost factors (Dmax, Pmax, Mmax), 
which describe the limit that should not be exceeded by any protocol function that is 
included in the created protocol assembly. The comparison is done by calculating the 
15 total difference 

Ti = Dmax - Di + Pmax - Pi + Mmax - Mi (2) 

for the protocol functions satisfying (1). The fimction having the highest Ti is then 
20 selected to be included in the assembly. If the selected fimction requires also other 
functions to be included in the assembly to implement the service, the selection of 
these functions is done in the same manner. 

Figure 10 illustrates the above function selection process. In this example, a service 
25 can be implemented by including one of three functions, Functionl 1002, Function2 
1004, and Functions 1006, in the protocol assembly. First, levels of service factors (Q) 
are checked, and the Fimctionl 1002 is dropped as being not able to provide an 
adequate service level. Then the cost difference (T) according to (2) is calculated on 
the basis of which function2 1004 is finally selected due to a larger difference. 

30 

A list of protocol functions needed to implement all the required services can be 
formed in the above-described manner. The configuration manager passes the list to 
the CPE core that instantiates the required protocol functions from the CPE function 
library. It is noted that also other methods can be applied in the function selection 
35 process if found useful. The above solution is only a simplistic example, being 
however quite feasible if more sophisticated solutions are not necessary. 
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In addition to the selection and instantiation of protocol functions, the needed 
interfaces and data queues are initialised. After this, the configuration is ready and 
CPE can be used for data transfer. 

5 Further reverting to the CPE scheduling algorithm for a moment, as the configuration 
information defines the required services and the associated QoS values, the CPE 
scheduler may create a separate queue for each required QoS (priority) value/class, and 
in the most simple implementation, just handle/serve the various service primitives (or 
derivatives thereof, e.g. modified primitives with added/deleted data) placed into the 
1 0 queues by controlling the processing of the queues according to the related QoS value 
in decreasing order. 

Priority as a concept, however, should be interpreted more broadly than just a single 
QoS parameter that defines a proper queue for a primitive. Instead, priority refers to a 

15 general importance of e.g. a service, a service primitive, or a group of 
services/primitives respectively, and therefore may actually affect the service 
requirements and service levels including both software and hardware aspects. Thus, a 
number of different priority factors may exist for a certain service/primitive. Then, for 
example, part of the priority information may indicate how the data associated with a 

20 certain priority should be secured/protected (e.g. channel coding, encryption) in 
addition to mere latency issues handled by the priority queues. 

A need for adjusting the current CPE configuration may arise while using CPE for data 
transfer. The CPE user may need some additional protocol services or some services 

25 are not required any more. Such situation may be caused by the change in the available 
hardware or network resources, data priority levels or the other protocol layers 
surrounding the CPE. Because of the changes, a new set of configmration information 
must be specified. The CPE management user delivers this information to CPE and the 
(re)configuration is initiated. Before instantiating new protocol functions or interfaces, 

30 and creating new data queues based on the new configuration information, CPE is reset 
using either a soft or hard reset request. After this, the reconfiguration process goes 
through the same phases as the boot-time configuration of the CPE presented 
hereinbefore. If only minor changes are needed, a supplementary configuration update 
message may be specified in order to alter/insert/delete a certain service in the 

35 otherwise still applicable existing configuration, for example. 
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As one possible use case of the invention, a sketch of a video transmission system is 
presented in figure 11. Real-time video streaming services are becoming more and 
more popular and can even be utilized by the modem mobile hand-held devices such as 
mobile terminals. Therefore, it's not an unusual scenario to occur in which a video 
5 server system 1102 encodes 1106 and transmits coded video data to a device that can 
be located either at the end of some fixed or wireless connection respectively. For 
example, the case-specific far-end client that can be e.g- a mobile terminal 1112, a 
PDA/laptop 1114, or a personal (desktop) computer 1116, may bear wireless 
coimectivity means like GSM, WLAN (Wireless Local Area Network) or Bluetooth 
10 radio transceiver, or interfacing means for wire transmission like an Efhemet adapter. 

Traditionally oriented approach in aforesaid cases for supporting different data 
transmission techniques in the server system 1102 has been the installation of 
additional protocols/several parallel protocol stacks and/or a pluraUty of specific 

15 interface cards providing the necessary transmission technique specific transceivers 
and/or supplementary protocols to the server device. Thereupon, the resulting 
arrangement has surely not been optimised in relation to memory consiunption, 
configurabiUty, or adaptivity issues etc. For real-time video streaming, a protocol stack 
that is transparent firom the application's vieAvpoint would be beneficial as the coder 

20 could then directly control e.g. retransmissions and bit error protection. As varying 
channel conditions like noise, fading effects, and congestion, typically cause problems 
to data transmission; these factors should be taken into accovmt upon transferring video 
data. Advantageously, e.g. used video coding, ciphering, and protection (chaimel 
coding and error concealment, for example) methods should be separately adapted to 

25 different connection types even during a connection due to changed channel conditions 
or some other factor. It's now obvious that the CPE 1110 could be used to construct a 
transparent adaptive protocol (stack) to overcome the above dynamic scenarios as 
described hereinbefore. Moreover, the CPE may be configured to take care of 
functionalities otherwise handled by the application itself. The encoder 1106 can 

30 provide the CPE 1110 initial configuration information in order to set up the necessary 
interfaces, to instantiate proper functions, and to organize the scheduling of different 
video service primitives with a plurality of queues; the CPE 1 1 10 is acting as a flexible 
VCP (Video Control Protocol) 1104 firom there on. Instead of otherwise inevitably 
quite complex protocol stmcture with several vertical (and possibly horizontal) layers a 

35 single CPE entity 1110 may be thus configxired to provide at least most if not all 
services/functionalities necessary for reliable, transparent and fast video transmission. 
This feature is highlighted in the figure by representing the CPE as an object with 
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single input/output arrows and a dotted feedback arrow describing the various internal 
connections and processing chains. Likewise, the cUent devices 1112, 1114, and 1116 
may utilize the CPE for data (including signalling) reception and transmission, and be 
that way enabled to connect to a variety of services over different protocol 

5 arrangements without redundancy introduced by parallel protocol stacks. Situations 
may occur in which the server can be folly packed with different partly overlappmg 
software and hardware solutions without problems but the same processing, memory, 
and maybe even physical space resources (e.g. in small-sized terminals) do not exist in 
the cUent side, and the CPE may be used to cut down unnecessary processing and 

10 memory usage, for example. The cUent device may bear a plurality of physical 
connecting means (multiple or adaptive transceiver arrangements, network adapter) 
and then utiUze the CPE to provide flexibly configurable upper protocol layer(s) for 
successfol service reception. 

1 5 Thus, the mterface 1 108 for actual physical (protocol) layer concerning both the server 
and the client devices can be carried out by the fonctionalities both in. the CPE and in 
various physical interface adapters, or by embedding necessary hardware means to the 
CPE module, or just by letting the separate physical interface(s) 1 108 to folly take care 
of the low-level transmission over the physical interface. 

20 

A method of the invention for configuring and constructmg a protocol by utilizing the 
CPE concept is described with the help of figures 12A and 12B, the former of which 
disclosing the CPE internal flow diagram upon receiving a service 
primitive/configuration, information and the latter disclosing the few events taken 
25 during the CPE configuration process in more detail. 

In step 1202, the method execution is ramped-up, e.g. the necessary hardware is 
configured, related software is loaded to the memory of the executing device, and 
various parameters are set to their initiaUsation values. Upon receivmg data entity 

30 either through the user or management SAP 1204 and corresponding interfaces, a 
proper execution path is selected. If the incoming data is a standard service primitive, 
its type is determined in step 1206 meaning the SCTvice identifier is extracted firom the 
primitive by the CPE core (primitive control block) in order to place it to a proper 
queue (handled by the queue control block) that is done in step 1208. The primitive is 

35 not processed until the primitives with higher priority (or with equal priority but 
received earlier thus having a higher position (i.e. primitive at the top to be processed 
next) in the queue) have been served 1210, this being taken care of by the scheduler 
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algorithm, after which the function control block drives the primitive data through 
requked functions in step 1212, Then the processed data is placed in a proper outgoing 
queue 1214 to be delivered to the adjacent protocol layer in step 1220. The method is 
ended or re-started in phase 1222. In case of configuration information that has been 
5 defined by the management user and delivered to the CPE, the configuration manager 
&st analyses the information by, for example, calculating the aforesaid cost factors for 
function selection etc in order to define 1216 the actual CPE configuration. The CPE 
configuration is taken into use by delivering necessary instructions for instantiatiug 
suitable functions and for creating required interfaces and primitive queues to the 
10 protocol core 1218. The CPE core then adapts to the newly received configuration. 

In figure 12B the adaptation phase 1218 is further illustrated via a three-step process: 
interface configuration 1224, queue/scheduler configuration 1226, and function 
configuration (-selection) 1228. The execution order of the presented steps is not a 
1 S critical issue though. 

Figure 13 depicts basic components of a device like a mobile terminal or a computer 
capable of processing, storing, and transferring data in accordance with the invention. 
Memory 1304, comprised of one or more physical memory chips, includes necessary 

20 CPE code 1316, e.g. in a form of a computer program/application, and necessary data 
(and/or necessary firee data space) like the CPE configuration 1312 and a number of 
queues 1314 for the primitives. A processing unit 1302 is required for the actual 
execution of the code 1316, albeit at least part of the CPE functionality can be carried 
out with specialized hardware 1318, for example. Display 1306 and keypad 1310 are 

25 optional components for providing necessary device control and data visualization 
means (--user interface) to the users. Data transfer means 1308, e.g. a radio transceiver, 
a serial/parallel bus, or a network adapter are required for handling actual physical 
level data (including standard service primitives and configuration information) 
exchange with other devices. The code 1316 for the execution of the proposed engine 

30 can be stored and delivered on a carrier medium like a floppy, a CD or a memory card. 

Thus, the CPE may be constructed as software, hardware or a combination of both. 
Such hardware may include microprocessors, microcontrollers, programmable logic 
chips and various circuit arrangements. In addition, the CPE can be realized as a 
35 separate module that is coimected to the existing system. The module may act between 
different system components or as an intermediate entity between two different 
systems. 
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The configuration information acting as a CPE configuration source can be delivered 
to the CPE manager as presented hereinbefore to be cultivated into an actual (final) 
CPE configuration by the manager and to be taken into use by the CPE core- However, 
5 the CPE configuration can also be explicitly constructed and possibly verified (by 
utilizing predefined configuration test software that matches the configuration to the 
specifications determining allowed parameter combinations, for example) by the 
managing or some other external entity to be only delivered to the CPE for direct 
utihzation without further calculations. Likewise, new fimctions may be added to the 
10 function library by utilizing the network connections. They must, however, follow the 
general rules defined for admissible functions in the CPE, and either the entity that is 
about to provide the functions or the CPE engine itself may utilize various self-test 
programs in order to verify proper composition of the constructed/received functions 
before transmission/adoption. 

15 

The scope of the invention can be foimd in the following claims. However, utilized 
devices, method steps, configuration information, protocol internal structure, message 
and data structures etc may vary depending on the scenario, still converging to the 
basic ideas of this invention. For example, it is clear that the invention can be utilized 
20 in many different systems, not only in connection with the OSI model that was 
mentioned and used as a starting point for modifications in this text only due to its 
evident popularity in communication systems in general. Moreover, it is noted that the 
numeric values and numeric ranges used in the text are only exemplary and sxurely not 
the only ones applicable to exploitation in the CPE. 

25 
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